home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 5⁄18⁄90 / 1298-UnloadAllSegs-May90 < prev    next >
Encoding:
Text File  |  1990-05-18  |  3.6 KB  |  93 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  PHAC         to DOUGLASS1    MEIER1
  2.  
  3. Item    7027909                         15-May-90        14:20PDT
  4.  
  5. From:   CDA0004                         VAR Shana Corp, Don Murphy,IVR
  6.  
  7. To:     MACDTS                          Macintosh Developer Tech Supt
  8.         MACAPP.TECH$                    MacApp Technical
  9.         CAN.DTS                         Canada Development Support Group
  10.  
  11. Sub:    UnloadAllSegs
  12.  
  13. Attn: Keith Rollin
  14. Attn: MacApp.Tech$
  15. Attn: Canada DTS
  16. SentBy: Wayne Malkin
  17. Date   5/14/90
  18. Subject    UnloadAllSegs
  19. From   Wayne Malkin
  20. To Keith Rollin
  21.    Canada DTS
  22.    MacApp.Tech$
  23.  
  24.  Memo         Subject:UnloadAllSegs
  25.  
  26. Keith,
  27.  
  28. Here is an update on the UnloadAllSegs hack I sent to you some months back.
  29.  
  30.  
  31. The Story So Far:
  32.  
  33. To refresh everyone's memory, the idea was to patch LoadSeg and monitor the
  34. amount of code that is loaded before attempting to load another segment. If
  35. the loaded code exceeded some value, the LoadSeg patch would call
  36. UnloadAllSegs before loading the requested segment.
  37.  
  38. To make this work, UnloadAllSegs was modified to do a stack crawl and
  39. determine what segments were in the current call chain. These segments would
  40. not be unloaded. The effect of all this is to reduce the maximum loaded code
  41. by at least 50%.
  42.  
  43. When UnloadAllSegs is only called from the main event loop, the maximum amount
  44. of loaded code is the sum of all segments that get called as a result of a
  45. single user action. When UnloadAllSegs is called from the LoadSeg patch as
  46. well, the maximum drops to the maximum length of a single chain.
  47.  
  48. The first problem was that the stack frames are not consistent when LoadSeg
  49. gets called from the jump table. Because no LINK instruction is performed in
  50. the jump table, there is no reference to the routine that called into the jump
  51. table. I faked up a stack frame in the LoadSeg patch to work around that
  52. problem.
  53.  
  54.  
  55. This Week's Episode:
  56.  
  57. This "hack" has been working beautifully in a shipping product (600 copies
  58. sold so far) for 3 months. While working on the next release, I found an
  59. additional nasty problem. (luckily, it's not in the current release...)
  60.  
  61. The problem is in the failure mechanism. CatchFailures saves registers,
  62. including A6, and Failure restores these registers before calling the failure
  63. handler procedure. This is ok as long as the failure handler is local to some
  64. procedure that is still in the call chain. The stack frames are all correct.
  65.  
  66. However, if the failure handler is in the global scope, there is a good chance
  67. that the stack frames will have gone away.
  68.  
  69. In my example, a CatchFailures was done in a global routine, with another
  70. global routine as the failure handler. Once the routine that posted the
  71. CatchFailures returns to its caller, the A6 that was saved for the failure
  72. handler becomes invalid. Since it is a global routine, that is not
  73. particularly relevant, except that if UnloadAllSegs gets called from this
  74. failure handler (as a result of a LoadSeg), there is no way to determine what
  75. segments are still in the call chain, because there is no valid stack crawl.
  76.  
  77. The only solution I could come up with on short notice was to use a global to
  78. disable the unloading of segments while the global failure handler was
  79. executing.
  80.  
  81. Since there is nowhere for the failure handler to go, it might be possible to
  82. determine the stack frames by looking at the saved value of A6 in the next
  83. failure handler. I didn't play around with this, though.
  84.  
  85. Apart from this one problem, everything has been working GREAT for a few
  86. months. The benefits are immense, since our maxiumum code reserve dropped from
  87. 450k down to 140k.
  88.  
  89.  
  90. -- Wayne Malkin
  91.  
  92.  
  93.